1. Field of the Invention
The present invention relates generally to diagnostics in computer information systems. More specifically, the present invention relates to systems and methods for retaining a record of and managing output from software applications (as well as directing tasks associated with such output).
2. Background of the Invention
The Regional Bell Operating Companies (RBOCs) use hundreds of computer software applications to manage everything from repair crews to requests for telephone service. Many of these software applications, such as 102, 104, and 106 of FIG. 1, generate notification messages.
A software application generates notification messages for many reasons, but most often to alert technicians that the software application has erred or has encountered some error. In these cases, the notification messages are intended to alert certain technicians whose task it is to make sure the software application runs properly.
To aid the technicians, most software applications store each notification message into an output file so that the technicians can read and have a record of the errors created or encountered by a particular software application.
Using FIG. 1 as an example, if software application 102, 104, or 106 generates a notification message, shown at steps 108, 101, or 103, respectively, it or some other program stores the notification message into an output file 110, 105, or 107, respectively.
While the output file aids the technicians by recording the notification messages from the software application, to be optimally useful, a technician must constantly track the output file or the errors may go unattended. Usually, however, a technician is not sitting in front of a screen, constantly reading over the output file, waiting for each new notification message to arrive.
To fix this problem, most of the RBOCs use system monitors. A system monitor is another software application that monitors the output files. Some system monitors send an email to technicians containing the text of each notification message as soon as the notification message is generated by the software application and added to the output file. This type of system monitor helps alert the technicians, but the technician still must be at his or her computer to receive the notification message or an error may go unattended.
Moreover, this type of system monitor bombards technicians with huge numbers of notification messages—every notification message generated by monitored software applications. Because most of these notification messages are not important, technicians must review many useless emails, and can lose track of important messages that are among a sea of unimportant ones. In short, this type of system monitor is disadvantageous because it does not clarify which notification messages are important.
To correct this failure, programmers designed system monitors to include message databases, usually one database for every software application for which the system monitor was intended to monitor (by monitoring that software application's output file). The system monitors use these message databases to separate the important from unimportant notification messages.
Using FIG. 2 as an example, system monitor 122 contains message databases, which system monitor 122 uses by comparing each notification message in output file 110, 105, or 107 against notification messages previously recorded into the message database (shown in process step 112). When comparing, system monitor 122 uses just the message database corresponding to the software application that generated the notification message. Thus, system monitor 122 may contain multiple system monitor message databases, each containing notification messages that can be generated by a particular software application, such as 102, 104, or 106 of FIG. 1.
Each system monitor message database typically contains the text of the notification messages that the software application to which it corresponds could generate, but only contains those notification messages that the software application could generate at the time the message database was completed. With every update, bug fix, or other change to the software application to which the message database corresponds, the messages database becomes more and more out of date—no longer containing all of the notification messages that the software application can generate.
For notification messages a software application generates of which a message database contains a copy, however, the system monitor can determine whether or not those notification messages are important or unimportant. As an example, system monitor 122 in FIG. 2 does so by comparing each notification message contained in output file 110, 105, or 107 against the related system monitor message database. If the newly generated notification message matches an identical notification message contained within the message database, system monitor 122 accesses information associated with that identical notification message from the message database. This information informs system monitor 122 of whether or not the notification message is important (see process 112).
For example, if the notification message is “error 24: disk memory almost full” and the system monitor message database contains an identical notification message “error 24: disk memory almost full”, system monitor 122 learns all information stored in the message database corresponding to that exact notification message. System monitor 122 could learn that it should alert a certain person and that the notification message is of a particular importance (also called severity). Thus, system monitor 122 could send an email to that certain person according to process 1118 (technician number 4 at technician4@RBOC.com, for instance) alerting the technician, according to step 120, of the severity of the error to which the notification message, “error 24: disk memory almost fall” refers.
System monitors are only able to alert technicians of the importance of a particular notification message if the applicable message database contains a notification message identical to that particular notification message. Without information from a message database, a system monitor must guess as to the notification message's severity and to whom to send an alert.
The system monitor will have less and less information from the message database as the message database gets out of date. The message database gets out of date over time as the software application that the message database relates to changes. The software application can change through bug fixes, updates, upgrades, and in other ways.
The system monitor also will not have information from the message database for inaccuracies in the message database.
For every notification message that is generated by the software application for which the message database does not have an exact match, the system monitor will fail to provide a good estimate of the severity of such non-matching notification messages, and will fail to provide a good estimate of who to send an alert regarding such non-matching notification messages.
Using FIG. 2 as an example, for notification messages without a match in a message database, system monitor 122 can only send out a general email, without a meaningfully choosing a severity, to a general contact list of technicians, as shown in step 114. While the technician is alerted, step 116, of a the notification message, the alert is one of many such general emails bombarding the technicians; the technicians must spend considerable time reviewing these general emails. This is because the technician cannot determine which email is important without reading through them.
Even worse, most technician receive notification messages from more than one software application—sometimes dozens of software applications and multiple system monitors—further bombarding the technician with general emails with nothing but the text of the notification message and an average or general severity level. This requires the technician to read the emails and, unless the technician is unusually diligent, causes many important notification messages to go unattended. When notification messages go unattended, errors discovered by or occurring in the software application generating the notification messages may cause the software application to fail, sometimes causing substantial losses or interruptions to the business.
Because system monitor 122 must sent out an alert to a general contact list for every non-matching notification message, the email goes to too many technicians or fails to go to the right technicians. By doing so, system monitor 122 fails to direct notification messages to the technician most likely to be responsible for and capable of fixing the error.
The process shown in FIG. 2 of monitoring notification messages also fails in another manner; it fails to adequately encourage and assist technicians who fix an error to update the applicable message database used by the system monitor. In this process, there is no feedback system requiring and encouraging technicians to update the system monitor message database. The technicians are also disincentivized to update the applicable system monitor message database because in the current process, it must be done by hand by opening up the system monitor message database and carefully typing in the notification message, new severity, and new email list.
Even when the technician does update the applicable message database, it is an inefficient process. First, the technician may have to wait until the system monitor is no longer using the particular system monitor message database, increasing the chance that the technician will forget important information by the time that window of opportunity opens. Second, the technician must record all the relevant information relating to fixing the error without prompting or assistance. Because of this, the technician may fail to retain all of the information pertinent to the update. Third, the process is inefficient because it requires the technician to reenter the information into the system monitor message database that the technician recorded earlier, wasting the technician's time.